1. Field of the Invention
The present invention is directed to distributed transaction processing systems. More particularly, the present invention is directed to methods and apparatus for testing components of a distributed transaction processing system that implements the X/Open Distributed Transaction Processing model.
2. Description of the Prior Art
On-line transaction processing (OLTP) is a technology that has been used successfully for business-critical applications by large enterprises for many years. With OLTP, users at terminals send messages to application programs, and these in turn update databases in real time. This is in contrast to batch or queued processing of transactions where the transactions are processed at a later time.
An example of an OLTP application is an airline reservation system. When a travel agent sends a request to reserve a seat on a plane, a database is updated accordingly, and a confirmation message is sent back to the agent'terminal. All of the tasks are part of a single transaction, and many agents can perform transactions at the same time. OLTP systems are typically used in environments that support large numbers of users, all accessing the same database, with hundreds and sometimes thousands of transactions taking place each second. The systems are typically based on large enterprise servers that can provide the performance, reliability, and data integrity demanded by these environments.
A transaction may be thought of as a set of actions performed by a transaction processing system wherein the actions together exhibit the properties of Atomicity, Consistency, Isolation, and Durability (ACID). The following definitions are given in Transaction Processing: Concepts and Techniques, by Jim Gray and Andreas Reuter, Morgan Kaufmann Publishers, Inc., 1993, p. 6:
Atomicity. A transaction'changes to the state are atomic; either all happen or none happen. These changes include database changes, messages, and actions on transducers.
Consistency. A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.
Isolation. Even though transactions execute concurrently, it appears to each transaction, T, that other transactions execute either before T or after T, but not both.
Durability. Once a transaction completes successfully, (commits), the state of the data is changed to reflect the successful completion of the transaction, and the state of the data will survive system failures.
To maintain the properties identified above, at the beginning of processing a transaction, a transaction processing application program typically invokes some form of begin-transaction function to indicate processing of a transaction has begun. This operation is typically logged to an audit file to demarcate the operations associated with the particular transaction. Following the begin-transaction function, the other functions associated with the application-defined transaction are performed and are also logged to an audit file. If all operations associated with a transaction complete successfully, a commit function is invoked to make permanent any state changes that have occurred as a result of the transaction. The commit operation is logged to the audit file to indicate that all operations have completed successfully. If an error occurs during processing of the transaction and a commit operation is not performed, a rollback function is invoked to undo the effects of the operations performed to that point in processing the transaction.
Distributed Transaction Processing (DTP) is a form of on-line transaction processing that allows a single transaction to be performed by multiple application programs that access one or more databases on one or more computers across a network. This type of transaction, in which multiple application programs cooperate, is called a distributed transaction. Using DTP, for example, related databases at regional and branch locations can be synchronized. DTP also facilitates transaction processing across multiple enterprises. For example, DTP can be used to coordinate the computers of manufactures and suppliers, or to coordinate the computers of enterprises in related industries, such as the travel agency, airline, car rental, and hotel industries.
Transaction processing in a distributed environment can be either non-global or global. In a non-global transaction, the same work takes place as in a traditional transaction, but the work is distributed in a client/server manner. For example, a travel agent may request an airline reservation via a client application program that has a graphical user interface. The client application program communicates with a server application program that manages the reservation database. The server application program updates the database, commits or aborts its own work, and returns information to the client application program, which notifies the travel agent.
A global transaction consists of multiple, coordinated database updates, possibly occurring on different computers. Global transactions are used when it is important that all databases are synchronized so that either all updates are made or none are made. Continuing with the previous example, the travel agent may also need to reserve a rental car and hotel room. The customer who is traveling wants to make sure that all reservations are coordinated; if a flight is unavailable, the hotel and car reservations are not needed. For the purpose of illustrating a global transaction, the airline, car, and hotel databases are on different transaction processing systems.
The global transaction begins when the travel agent requests the reservation from a workstation client application program with a graphical user interface. The client program contacts three server application programs on different transaction processing systems. One server program books a flight, another reserves a car, and the third makes a hotel reservation. Each of the server application programs updates its respective database. The transactions processed by each of the server application programs may be referred to as subordinate transactions of the global transaction. A global transaction manager coordinates the updates to the three databases, and a subordinate transaction manager on each of the individual transaction processing systems coordinates locally with the server application programs. The server application programs return information to the client application program.
A major advantage of global transaction processing is that tasks that were once processed individually are processed as a group, the group of tasks being the global transaction. The database updates are made on an all-or-nothing basis. For example, if an airline seat is not available, the hotel and car reservations are not made. Thus, with a global transaction, tasks that were once performed independently may be coordinated and automated.
As with non-global transactions, global transactions must possess the ACID properties. In order to preserve the ACID properties for a global transaction, the commit processing is modified to a two-phase commit procedure. Under a two-phase commit, a global transaction manager first requests that each of the subordinate transaction managers prepare to commit their updates to the respective databases. If all the local transaction managers respond that they are prepared to commit, the global transaction manager sends a commit request to the local transaction managers. Thus, the two parts of the two-phase commit process are (i) prepare to commit the database updates, and (ii) commit the database updates. If any one of the transaction managers is unable to commit, the entire global transaction is aborted and each transaction manager performs a rollback function to undo the processing that may have occurred up to that point. In short, the two-phase commit process ensures that multiple databases participating in a single global transaction are synchronized--either all database updates requested by the global transaction are made or, in the event of system or component failure, none are made. Two-phase commit guarantees global data integrity and preserves the ACID properties in a DTP environment.
An industry consortium of users and vendors, known as X/Open.TM., has developed a model architecture for DTP, referred to as the X/Open Distributed Transaction Processing model. The X/Open DTP model is a software architecture that allows multiple application programs to share resources provided by multiple resource managers, and allows their work to be coordinated into global transactions. The X/Open DTP model comprises a number of components, application programming interfaces, and communications interfaces.
FIG. 1 illustrates a client system 10 and a server system 12 both constructed in accordance with the X/Open DTP model architecture. Referring to the client system 10 as an illustrative example, the components of the X/Open DTP model include an application program (AP) 14, one or more resource managers (RMs) 16, a Transaction Manager (TM) 18, and a Communications Resource Manager (CRM) 20.
An Application Program (AP), such as client application program 14, is a user-defined software component that defines global transaction boundaries and specifies actions that constitute global transactions. It also provides access to one or more resources that are required by a transaction, In a global transaction, two or more APs perform their individual functions which, when combined, make up the global transaction. One of the APs will be the superior AP, that is, the AP that starts and finishes the global transaction. The other APs will be subordinate. A hierarchy of APs may be established where a subordinate AP is superior to another AP. In the example of FIG. 1, the client application program 14 might be the superior AP, and the server application program 40 the subordinate AP.
A Resource Manager (RM) 16 provides access to a resource for the AP 14. The X/Open DTP model permits multiple resource managers. Database management systems and file access systems are examples of system software components that act as RMs.
The APs begin and end transactions under the control of the Transaction Manager (TM) 18. The TM 18 is a system software component that assigns transaction identifiers to global transactions, monitors their progress, coordinates their completion, and coordinates failure recovery. The TM enforces the transaction property of atomicity. If a global transaction is being processed, the TM adheres to the two-phase commit transaction processing protocol.
The CRM 20 controls communication between the AP 14 and other APs (e.g., AP 40) that are participating in global transactions, as well as between the TM 18 and TMs on separate data processing systems (e.g., the TM of system 12).
The X/Open DTP model provides a number of standard application programming interfaces that enable application programs to interact with system components to conduct global transactions. These application programming interfaces include one or more AP-RM interfaces 22, an AP-TM interface 24, an AP-CRM interface 26, one or more RM-TM interfaces 28, and a TM-CRM interface 30.
The AP-RM interfaces 22 provide the AP 14 with access to resources (such as databases) through their respective RMs 16. These interfaces are not specifically defined by the X/Open DTP model, as a number of different resources can exist on a system. Examples of AP-RM interfaces include the Structured Query Language (SQL) and the Indexed Sequential Access Method (ISAM).
The AP-TM interface 24 is provided by the TM 18 to define global transaction boundaries. The AP-TM interface is also referenced as the TX interface. Further information on the TX interface is available in Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K., (1992). The TX interface is described in somewhat greater detail below.
The AP-CRM 26 interfaces are provided by the CRM 20 to the AP 14. The X/Open DTP model supports the following three AP-CRM interfaces: the TxRPC interface, the XATMI interface, and the CPI-C interface. Each of these interfaces can be used to enable communication between APs that utilize the same interface. The present invention relates in particular to systems that implement the XATMI interface. Although the XATMI interface is discussed below in somewhat greater detail, further information on the XATMI interface is available in Distributed Transaction Processing: The XATMI Specification, X/Open Company Limited, U.K., (1993), which is hereby incorporated by reference in its entirety.
The TM-RM interfaces 28 are similar to the AP-RM interfaces 22 and are used for purposes of transaction control (preparing, committing, or rolling-back). The TM-RM interfaces 28 and TM-CRM interface 29 are described further in XA Interface, Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K., (1992).
In addition to the foregoing application programming interfaces, systems that implement the X/Open DTP model can communicate with each other using the Open Systems Interconnection (OSI) Transaction Processing (TP) communications protocol 34 (ISO/IEC 10026). OSI TP is a machine independent protocol that supports communications between computers in a transaction processing system. XAP-TP 32 is a standard interface that provides access to OSI TP services. It serves as the interface between a CRM 20 and the OSI TP protocol 34 to initiate and support communications between local and remote application programs within a DTP system. The XAP-TP interface 32 is described in detail in the X/Open specification entitled ACSE/Presentation: Transaction Processing API (XAP-TP).
Lower layer communication protocols 36 handle the low-level communication chores needed to send information between systems 10 and 12 via a network 38. These lower layer protocols 36 can, for example, be OSI or TCP/IP. The X/Open DTP model does not define an interface to these lower layers.
As the present invention relates particularly to X/Open DTP model-based transaction processing systems in which the CRM component implements the XATMI AP-CRM interface, further details of the XATMI interface follow.
The XATMI interface relies principally on the following API requests supported by the TX interface:
tx_begin( )--a demarcation function that indicates that subsequent work performed by the calling AP is in support of a global transaction; PA1 tx_commit( )--a demarcation function that commits all work done on behalf of the current global transaction; and PA1 tx_rollback( )--a demarcation function that rolls back all work done on behalf of the current global transaction.
Further details of the TX interface can be found in Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K., (1992).
The XATNU API provides a set of function calls, collectively referred to as the tp*( ) function calls, that can be called to perform various functions. The following is a list of these functions, callable from any C language application program:
Name Description Typed Buffer Functions tpalloc( ) Allocate a typed buffer. tpfree( ) Free a typed buffer. tprealloc( ) Change the size of a typed buffer. tptypes( ) Determine information about a typed buffer. Functions for Writing Service Routines tpservice( ) Template for service routines. tpreturn( ) Return from a service routine. Functions for Dynamically Advertising Service Names tpadvertise( ) Advertise a service name. tpunadvertse( ) Unadvertise a service name. Functions for Request/Response Services tpacall( ) Send a service request. tpcall( ) Send a service request and synchronously await its reply. tpcancel( ) Cancel a call descriptor for an outstanding reply. tpgetrply( ) Get a reply from a previous service request. Functions for Conversational Services tpconnect( ) Establish a conversational service connection. tpdiscon( ) Terminate a conversational service connection abortively. tprecv( ) Receive a message in a conversational connection. tpsend( ) Send a message in a conversational connection.
Each of the foregoing XATMI API requests has a formal syntax that specifies the format and arguments of each request. The formal syntax for each request is specified in Distributed Transaction Processing: The XATMI Specification, X/Open Company Limited, U.K., (1993).
The XATMI interface supports typed buffers through the typed buffer functions listed above. A typed buffer contains data and has associated with it a type and possibly a subtype, that indicate the meaning or interpretation of the data. An AP calls tpalloc( ) to allocate a typed buffer of a specified type and subtype, can call tprealloc( ) to increase its size, and must eventually call tpfree( ) to dispose of it. A receiver of a typed buffer can call tptypes( ) to determine the type and subtype of a buffer as well as its size.
Generally, there are two types of services supported by the XATMI interface--request/response services and conversational services. In the request/response service paradigm, requests can be issued to services in two ways: synchronously or asynchronously. The tpcall( ) function sends a request to a specified service, and returns any response in an application-defined typed buffer. The call to tpcall( ) returns after any expected response arrives. The tpacall( ) function also sends a request to a specified service, but it returns without waiting for the service'response, thereby letting the requester do additional work while the service routine processes its request. The tpgetrply( ) function waits to receive a service reply corresponding to a specified request, and returns the response in an application defined typed buffer. A requester not wanting to receive a reply to a particular request can use the tpcancel( ) function, which informs the CRM that any response should be silently discarded.
In the conversational service paradigm, a requester invokes a service routine and converses with it in an application-defined manner. Conversational communication with a service is initiated by calling the tpconnect( ) function. The service name and application data can be passed to the service as parameters of the call. A descriptor is returned that the requester subsequently uses to refer to the newly established connection. tpsend( ) and tprecv( ) are used by APs to exchange data over an open connection. Normally, a connection is terminated by the CRM after the service returns by calling tpreturn( ). If, however, a requester wishes to terminate a connection prematurely, the tpdiscon( ) function is used.
The functions tpservice( ) and tpreturn( ) are used to facilitate the writing of service routines in server application programs. A service routine is invoked from implementation specific dispatching code contained within a server. Handling of the communication path is independent of the service and is the responsibility of the CRM. tpservice( ) is the template for writing service routines, and can be used both for request/response services, as well as for conversational services. tpreturn( ) is used to send a service'reply message. If an AP is waiting for a reply as a result of either a tpcall( ), tpgetrply( ), or tprecv( ), then a successful call to tpreturn( ) by the service will place the reply in the receiving AP'buffer.
When a requesting AP uses either tpacall( ), tpcall( ), or tpconnect( ) to interact with a particular service, it passes a service name identifier to the service AP as a parameter to the call. When servers are started, they advertise the set of services that they offer by name, in an application-specific manner. tpadvertise( ) is used by a server to advertise a new service that it offers. The function has two parameters: the service name identifier and the actual C language routine that the server must invoke whenever a requesting AP requests that service by name. A server can use the tpunadvertise( ) function to unadvertise a service.
With systems that adhere to the X/Open DTP model, application programmers can develop custom client and server application programs (APs) to implement customized transaction processing applications, such as reservation systems, banking systems, and the like. In systems that have a CRM component that implements the XATMI interface, application programs (APs) make calls to the TM and CRM components of the system, via the respective TX and XATIMI interfaces, to initiate and execute global transactions. In general, a global transaction is processed as follows. An input message arrives at a client application program executing on one system. The client application program uses a tx_begin( ) primitive of the TX interface to start a global transaction. Thereafter, the client application program uses various XATMI primitives, such as tpcall( ), tpacall( ), and toalloc( ), to call various services provided by one or more server application programs executing on the same or other systems. The server application programs may use local RMs to update databases in response to the calls made by the client application program. When the work is done, the client application program will use the tx_commit( ) primitive of the TX interface to initiate the two-phase commit process and to coordinate that process among the client's TM and the TMs of the various service application programs involved in the transaction. Specifically, the initiating TM (the one that received the tx--begin( )) will communicate with all the other TMs to request approval to commit and update the databases. If all agree, the database will be updated. If any do not agree, then a rollback function is performed to return all databases to the state they were in before the transaction began. If the client application program and/or any of the server application programs reside on different computer systems, the two systems will communicate with each other using their respective CRMs, which are built on a foundation of OSI TP. As mentioned above, OSI TP provides services and protocols that assist the two-phase commit process and communication between systems. The OSI TP implementations on each system in turn operate across lower layer services and protocols that can, for example, be OSI or TCP/IP.
Typically, system vendors supply software suites for a given hardware platform that implement the RM, TM, and CRM components of the X/Open DTP model, along with tools that enable application programmers to develop DTP application programs (APs) that work in conjunction with the model. These vendors may also supply an implementation of the OSI TP standard to allow the RM, TM, and CRM components to interoperate with other systems that comply with the X/Open DTP model. For example, Unisys Corporation provides a suite of software products for its OS 2200 systems, called "Open/OLTP," that are based on the X/Open DTP model and OSI TP protocols. The Unisys Open/OLTP suite for OS 2200 systems includes an integrated TM and CRM. The CRM component supports the XATMI AP-CRM interface. The integrated product allows user-written client and server programs to use the TX and XATMI interfaces to the TM and CRM components to conduct global and non-global transactions. In addition, the Unisys Open/OLTP suite for OS 2200 systems includes an OSI-TP product that implements the OSI TP communications protocol, enabling user-written application programs (APs) to communicate with other APs on different systems. The integrated TM/CRM product relies on the OSI-TP product to establish and terminate dialogues with TMs on remote computers, to send and receive messages, and to coordinate commitment and rollback processing with the other systems.
While the X/Open DTP model and the set of specifications associated with the model describe the required functionality and API's that must be supported, the actual coding of TM, CRM, and OSI TP software components is left to the software developer. The program code developed to implement these components may vary widely from vendor to vendor, due to factors such as the programming language employed, and the underlying hardware platform on which the software is designed to operate. Consequently, any vendor of software that implements these components of the X/Open DTP model must be able to test the software to ensure its compliance with the associated specifications. One way to test these components is to exercise the TX and XATMI functions in an actual system environment to ensure that the system handles and executes the various functions correctly. However, developing sample application programs to perform a comprehensive test using the TX and XATMI interfaces is time consuming and requires that the tester be well-versed in the formal syntax of the various functions that each interface provides. In the case of the XATMI interface in particular, each of the functions provided that interface has a detailed formal syntax that requires calls to the various functions to be accompanied by various parameters. Building a test program containing sample calls to the various API functions using their formal syntax would be extremely time consuming and difficult for all but the most skilled programmers having an intimate knowledge of the XATMI API. Consequently, there is a need for a more efficient, and less complicated way to test the functionality of TM, CRM, and OSI TP components that support the XATMI API of the X/Open DTP model--one that does not require that the tester have an expert knowledge of the formal syntax of the XATMI API. The present invention satisfies this need.